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ABSTRACT 


Burroughs B1700 embodies a unique design ‘tenet: the work done to accommodate 
definable machine structure from instruction to instruction is less than the 
work wasted from instruction to instruction when one machine structure is 
used for all applications. In other words, execution of machine language 
using procrustean hardware causes more inefficiencies than soft interpreta- 
tion of arbitrary machine eueuace on protean hardware. 


The programs on the B1700 are not represented in 81700 machine language but 
in "S-language", that is, some other computer's machine language or a 
machine language invented an! Burroughs or by the user) expressly for the 
program's application area Interpretation of S- iahld eee a is s aided by: 
(a) bitraddressaki ‘pumenr’ geen THESES E War byess 
NOT Tictds, (c) eoial memory enced. on all bit locations and bit string 
lengths, (d) clock-by-clock control over the effective width of processor © 
data paths, registers, and structured logic elements, (e) soft microprograms, 
(f£) English language microprogramming, (g). execution of microcode in- 
differently from main memory or contre? memory, (h) enough control. memory 
to hold four interpreters and no limit on the number of interpreters that 
may be active at any given’ instant, (i)+ memory protection, (j) hard and 
soft interrupts, (k) stack jipanigeticn: (1) Master Control Program © 
taking full responsibility for efficient system utilization by means of 
interprtter multiprosramming and multiprocessing, user multiprogramming and 
multiprocessing, virtual control memory of 2 4 (over 16 million) bits, 
virtual main memory of 2 a (over 17 trillion) bits, soft. interpretation of 
I/O commands, and (m) automatic program profile statistics. Programs on 
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the B1700 are independent of: location, storage organization, I/O organi- 
zation, processor organization, peripheral idiosyncrasies, mix size, and 
system configuration (except for unique devices). Priced in the lowest 
system range, the B1700 offers time- and money-saving features not found 
on systems 100 times more expensive. 


The net result of this advanced system design is ease of use, simplé pro- 

gramming, lack of conversion costs, improved utilization of system com- . 

poneness and better price/performance. : : 

Keywords: computer avcniecctare, microprogramming, definable structure, 
B1700, S- language, interpretation - Gye 


‘I. - INTRODUCTION 


Procrustes was the ancient Attican malefactor who forced wayfarers to-lie 
on an iron bed. He either stretched or cut short each person's legs to 
fit the bed's length. Finally, Procrustes was forced onto his own bed by 
. Theseus. : Pala = | 


- Today the story is being reenacted. Von Neumann-derived machines are 
automatous malefactors who force programmers to lie on many procrustean 
beds. Memory cells and processor registers are rigid containers which 
contort data and instructions into unnatural fieids. As we have painfully 
learned, contemporary representations of numbers introduce serious diffi- 

culties for numerical processing. Manipulation of variable-length in- 
formation is excruciating. Another procrustean bed is machine instruc- 
tions, which provide a small number of elementary operations, compared to . 

the gamut of algorithmic procedures, Although each set is universal, in 

that it can compute any function, the scope of applications for which 

‘each is efficient is far smaller than the scope of applications for which — 
each is used. Configuration limits, too, restrict information processing 

tasks to sizes which are often inadequate. Worst of all, even when a 

program and its data agreeably fit a particular machine, they are con- 

| fined to that machine; few, if any, other computers can process them. 


In von Neumann's design for primordial Epvac!, rigidity of structure was 
more beneficial than detrimental. It simplified expensive hardware and 
bought precious speed. Since then, declining hardware costs and advanced | 
software techniques have shifted the optimum blend of rigid versus 
variable structures toward variability. As long ago as 1961, hardware 

of Burroughs B5000° implemented limitless main memory using wae ianies 
length segments. Operands have proceeded from single words, to bytes, 

a “ . 7 


1. See EDVAC, Burks, Goldstine, and von Neumann, 


2. See B5000, Lonergan and King. 
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to strings of four-bit digits, as on the B3500. The demand for instruc- 
tion variability has increased as well. The semantics of the growing 
number of programming languages are not converging to a small set of 
primitive operations, Each new language adds to our supply of funda- 
mental data structures and basic operations, 


This shifting milieu has altered the premises from which new system de- 
signs are derived. To increase throughput on an expanding range of 
applications, general-purpose computers need to be adaptable more 
specifically to the tasks they try to perform. For example, if COBOL 
programs make up the daily workload, one's computer had better acquire 
a "Move" instruction whose function is similar to the semantics of the 
COBOL verb MOVE. To accommodate future applications, the variability 
of computer structures must increase, in yet unknown directions. Such 
a reminds one of Preateut, the mary eEpsmensr anaes 
= “to that of any creature, 


2. DESIGN OBJECTIVE 


Burroughs B1700 is a pees attempt to donptetely vanquish procrustean 
structures, to give 100% variability, or the appearance of no inherent 
structure, Without inherent structure, there are no word sizes or data 
formats - operands may be eny shape or size, without loss of efficiency; 
there are no a priori instructions--machine operations may be any function, 
in any form, without loss of efficiency; configuration limits, while not 
totally removable, can be beyond state-of-the-art extremes; modularity — 
may be increased, to allow miniconfigurations and supercomputers using 
-the same components. _ | 


Del Design Rationale 


The B1700's permise is that the effort needed to accommodate definability 
from instruction to instruction is less than the effort wasted from in- 
struction to instruction when one system desisn is used for all applica- 
tions. With definable siructure, information is able to be represented 
according to its own inherent structure, Manipulations are able to be 
defined according to algorithms' own inherent processes. As long as one 
can define a machine environment which is more efficient for solving 
one's problems than a contemporary machine design, one can attain more 
throughput per dollar. As we shall see, there are novel machine designs 
which are 10 to 50 times more powerful than contemporary designs, and 
which can be interpreted by the B1700's variable-image processor. using 
less than 10 to 50 times the effort, resulting in faster running times, 
smaller resource demands, ang lower computation COSESe, 
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3, GENERAL DESIGN 


To accomplish definable structure, one may observe that during the next. 
decade, something less than infinite variability is required. As long © 
as control information and data are communicated to machines through pro- 
gramming languages, the variability with which machines must cope is 
limited to that which the languages exhibit. Therefore, it is sufficient 
to anticipate a unique machine environment for each programming language. 
In this context, absolute binary decks, console switches, assembly 
languages, etc., are included as programming language ooets of communica- 
tion, Let us call all such languases 'S=tengui é 
or also for "S68" or "sueecey or "épcin liz no | 
Machines which execute S-language directly are- onited "S-machines", The 
B1700's objective, consequently, is’to emulate existing and future S- 
machines, whether these are 360's, FORTRAN machines, or whatever. Rather 
than pretend to be good at all applications, the B1700 strives only to 
interpret arbitrary S-language superbly. The burden of performing well 
in particular applications is shifted to specific S-machines. Throughput 
measurements, reported below, show that the tandem system of: . 


application program 


interpreted by + 


S-machine 
interpreted b 
B1700 


. is more efficient than a single system when more than one applic ation area 
‘is considered. It is even more efficient than conventional design 
many individual application areas, such as sorting, 


To visualize the architectural advantage of implementing the S-machine con- 
cept, imagine a two-dimensional continuum of machine designs, as in 
Figures 1 and 2. Designs which are optimally suited to specific applica- 
tions are represented by bullets (s) beside the application's name. The 
goodness-of-fit of a particular machine design, which is represented as 

a point (*) in the continuum, to various applications is given by its” 
distance from the optimum-for each application; the shorter the distance, | 
the better the fit and the'more efficient the machine is. Figure l 
dramatizes the disadvantage of using one design for COBOL, FORTRAN, Emula- 
tion, and Operating System applications, Figure 2 petites the Sdvantade 
of Emulating/Interpreting many S-machines, each designed for a specific 
application. Note that Emulation inefficiencies must be counted once for 
each S-machine, since they are all interpreted. 
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Figure 1. Typical machine design positioned by goodness- 
. of-fit to application areas. 
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Figure 2. Typical B1700 S-machines positioned by 
| goodness-of-fit to application areas. 
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4. HARDWARE REQUIREMENTS 


Varying the processor's image for each application area implies very 
specific hardware requirements. 


4,1 | Defined-Field Capability 


All information is represented by fields, which are. (recursively) defined 
to be either bit strings or cae of fields; i. Coy bytes and words do 
not exist. : : 


(a) All memory is addressable to the bit. 
(b) All field lengths are eapecesabic to the bit... 


(c) Memory access hardware must fetch and store one 
or more bits from any location with equal facility. 
That is,: there must be no penalty and no premium 
attached to location or length. 


(d) All structured logic elements in the processor 
can be used iteratively and fractionally under 
microprogram control, thus effectively con- 
cealing their structure from the user, Iterative 
use is required for operands which contain more 
bits than a functional unit can hold; fractional 
use is required for smaller operands, 


4.2 _ Generalized Language Interpretation 


(a) The system should be capable of efficient inter- 
_ pretation of a variety of instruction formats. 


- (b) Format of interpreted instructions should not 
| be predetermined or limited. The structure of 
the system should not cause any significant 
difference in efficiency due to selection of 
format, | 


‘(c) HAteEprGtetion should be iy soft microprogram, 


— (d) Microprograms should Be chance able, shored and 


(e) Hardware must assist with the concurrent execu- 
tion of many interpreters, to make switching as 
napee as possible. 
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(f) eu coagn aope@a shite a a 
wiashbtGeee Microprogram execution is a critical 
part of the B1700. Some of the objectives in- 
volved in the design include: fast entry and 
exit of microprocedures, compactness of code and 
economy of storage, and ease of writing and 
maintaining microcode. 


(g). Microprograms must not be limited in size. Execu- 
-. tion of microprogram should be invisible to the 
user and not reflect any variation in ne erepr ere 
efficiency due to size, 


(h) Microfunctions must implement all present and 
foreseeable higher-level ‘language functions . 
efficiently but without prejudicing implementa- 

. tion of languages. Any function included solely 
for a single language should be in addition to 
basic microfunctions which could more generally 
implement the function, 


While the hardware requirements for defined-field design and generalized 
_ language interpretation have been stated so as to allow a varying pro- 
cessor image from microinstruction to microinstruction, they do not pre- 
clude taking advantage of a static processor image. For example, the 
number of bits to be read, written, or swapped between processor and 
_memory can be different in consecutive microinstructions, but if an 
interpreted S-machine's memory accesses are of uniform length, this 
length can be factored out of the interpreter, simplifying its code. 

In other words, S-memory may be addressed by any convenient scheme; bit 
addresses are available, but not obligatory for the S-machine. 


With these hardware advances, language-dependent Peneaxee such as operand 
length, are unbound inside the processor and memory buss, except during 
portions of selected microinstructions. Some of these features have, 
until now, been bound before manufacture, by machine designers. Language 
designers and users have been able to influence their binding only in- 
directly, and only on the next system to be built. On the B1700, the 
delayed binding of these features, delayed down to the clock pulse level 
of the machine, gives language eesteHers and users a new degree of flexi-— 
bility to exploit. 


4.3 Advanced Design 
On each newly designed system, professional responsibility dictates that 
previously proven advances in system organization be incorporated. 


4.3.1 


4.3.2 


- 4.3.3 


4.3.4 
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Virtual Memory 


(a) S-programs should not be limited in size; all 
' address fields should be variable. 

(b) S-programs should not reflect the storage 
- organization of the system. 


(c) Programmers should be given feedback on the 
| size and make-up‘of their working-sets. 


Stack Organization 


(a) Programs should be recursive and reentrant. 


(b) Subprogram entries and exits should be very | 
fast, to encourage decomposition of program- 
ming tasks into small, comprehensible units. 


(c) Conpiievion and execution efficiency should 
not be dependent on a manufacturer's ability 
- to solve register allocation problems. 


Dynamic System Configuration 


(a) Code should be independent-of system con- 
figuration, to allow addition and deletion 
of processors, memory modules, I/0 sie eae 
and RET eee while programs are running 


(b) The system itself base the user) should be 
responsible for full resource utilization; 
hence code should not have to change when the 
system is reconfigured. 


Multiprogramming 


(a) The system should run as many jobs at once 
as are necessary, subject to working-set 
limits, to keep each resource fully utilized. 


(b) Code should be independent.of the number of 
_ jobs in the mix, to provide equal efficiency 
when running alone as when running with 100 
others. : 


_(c) Memory must be protected from all invalid re- 


. ferences (read or wETEE) 


4.3.5 


4.3.6 


4.3.7 


4.3.8 
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(d) Hard interrupts are needed to manage asynchronous 
events with minimum overhead. 


Multiprocessing 


(a) The system should allow extra processors to be 
added to memory-rich or peripheral-rich installa- 
tions, to balance the system to user workloads. 


(b) Program state should be maintained outside of 
processors, to allow execution by any processor 
without excessive switching time, 


Descriptor-organized 1/0 


(a) System I/O is itself a unique application, deserving 
its own S- panguase and SRT EPREELETS 


(b) The 1/0 S-language interpreter may be sétt micro- 
program or a separate, wired processor, incapable 
of interpreting other S-languages. ; 


(c) With self-describing I/O requests, processor parti- 
cipation in I/0 is reduced, improving the system's 
ability to keep many peripherals in operation 

arco ae 


Soft rateerines 


(a) Asynchronous and infrequent events should not require 
explicit code for their individual detection. : 


Profile statistics 

(a) Program behavior should be analyzed and reported 
back to the programmer, or filed for overall system 
analysis, 


(b) Reports should be in terms of source language, 


(c) - Reporting which parts consume the most execution 
time is of primary importance. 


(d) Compilers writers ought to be told how their 
languages are being used. 


(e) By instrumenting soft microprogram interpreters for 
profile statistics gathering, overhead can be kept 
under 1%. 


PROCESSORS 


M- MEMORY 


PORT 
I/O CHANNELS INTER~ FIELD 

——— CHANGE J SOLATION 
oo ae UNITS 
= 

Each processor may have either 

1-8 1/0 channels or 1-4 micro~ 

program memory modules of 

16,384 bits cach. 

B1700 Organization 


Figure 3. 


S-MEMORY 


y 


Each system may have 
2-256 systems memory 
modules of 65,536 bits 
each, 


Available peripherals include - Card Readers: 300-1400 cpm models, 80.col.; 300-1000 cpm 
models, 96 col.3; Card Punch, 300 cpm, 80 col.; Card Read-Punch-Print-Sort, 1000/1000/126/ 


120 cpm, 96 col.; Card Record-Read-Punch-Print-Sort, 300/60/60 cpm, 96 col.; Line Printers 
ka -900 Ipm pode TS 132 col.; Paper Tape Peripherals: Disk Storage 5ms-40ms models, Head- - 
J-Track 2200-4400 bpi models, movable arm, cartridge; Magnetic Tape 7/9 Track, NRZI/PE 


models; Sorter-Reader 600-1625 dpm models; Data Communications See eg ee Graphics; 
Terminal Computers, Teller Machines, etc. 
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5. SYSTEM ORGANIZATION 


Extreme modularity improves the B1700's ability ‘to adapt to an instal}: 


requirements. There may be 1-8 processors connected to one another ai 
2-256 65,536-bit main memory modules, interfaced by one or more field- 
isolation units, described later. Each processor also connects to 1-8 
channels or to 1-4 microprogram memory modules. (See Figure 3.) 


tion's 
» to 


1/0 


“With only one processor, the port interchange may be eliminated, as in 


Figure 4. 


300 cpm 96-col, 


iA na Ge a ae a a tl See 

{300 Ipm_ 132 col. printer Lcontroi~{channel 

[dual spindle: : » toh — 
me dik [oe 


Figure 4. One of the smallest B1700's. 


Rental of the system in Figure 4 is expected to be under .$1500/month. 


MFCU Sea a rs 
‘ ee : coef seni fiu S-memory 
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6. EMULATION VEHICLE 


Any computer which can handle the B1700's port- to-port message discipline 
may employ a B1700 for on-line emulation, (See Figure 5.) 


M-memory Processor Port Interchange FIU - S-memory 


‘192K bits 


| 32K 
bits 


Communication line 
to host computer ~ 


Figure 5. B1700 as an Emulation Vehicle, 


Programs and data are sent to the B1700 for execution; I/0 requests are 
sent back to the host which uses its own peripherals for them. Inter- 
preters are loaded via the B1700's console cassette drive, Present 
interface specifications expect one interpreter to be in M-memory at a 

time, Rental of the system in Figure 5 is es a to be under Pee cuneate 


7. DEFINED-FIELD DESIGN 


7.1 


The mechanisms by which the processor and microinstructions automatically 
handle variable operand lengths and formats have come to be called "bias" 
facilities. In addition to a normal fag aR of Ease, Pasioe 


as S many as che processor car mand le; end 


CPiewhich specifies the unit of information, viz., bit, 
BCD, USASCII byte, EBCDIC byte, along with some 
open codes for future use. 
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eereepeer to determine when carries occur out of he pee re highest 

bit position. Memory-accessing microinstructions may choose to.access 

only as many bits as CPL specifies. ee ee 
~ ety Os on , 1 ss a ort a ~ ‘ i & pe ES 


PhOS. misrenrosran sequences 
which load CPL atid CPU from data descriptors (or even from the computer 
operator's keyboard) during an instruction interpretation behave correctly 
whether binary or decimal operands are supplied and whatever size the 
operands are. The microprograms are invariant to actual operand details, 
so the B1700 hardware appears not to have inherent structure. 


Iteration over operands which are longer than the processor can handle 
is Hecemp lense by two paws isa eaeee gars nan Bias and Count F. 


Cdrstead S oe have 2haBit canwedtst oes. PA oad SFA, for che: 
‘Ss bat address, 16-bit subregisters, FL and SFL, for the data's 
length (bit strings are thus limited to 65,535 bits), and 4-bit sub- 
registers, FU and SFU, for format information. The Bias instruction 
computes the format and number of bits to bring to the processor for an 
iteration by setting CPU from FU or SFU and by setting CPL to FL, SFL, 
itself, a literal value, or the minimum of any set of these. The Count 
F micro uses CPL or a literal value by which to increment and decrement. 
FA and FL; this indexes through an operand by defining contiguous sub- 
fields on which the processor may operate. To handle indefinitely long 
operands, then, one first writes a microprogram which assumes that the 
‘processor registers are indefinitely long. One suffixes the program 
with a Branch micro to repeat the code. One prefaces the program with 
a Count F and Bias pair, the Count F to define suboperands that are small 
enough to fit in the physical processor, and the Bias to compute the 
suboperand length (so that the operand need not be a multiple of the 
processor width), to load the bias registers, to test for completion, 
and to bypass the program when the long operand is completely processed. 
Such a microsequence can handle zero-bit to 65,535-bit operands indis- 
criminately.  . 


7.2 Bit-oriented Memory 


To implement bit-oriented memory at low cost, one uses conventional 
memories and a memory-requestor interface which is called a field isola- 
tion unit, or F.I.U. (see Figure 6). The FIU's tasks are to convert 

bit addresses, field lengths, and field directions (i.e., address refers 
to most- or least-significant-bit) into conventional addresses, to align 
requestor bit strings with actual memory containers, and to mask off 
honparticipating bits. During memory operations, bytes are read out 

of memory into the Memory Information Register, MIR, a bit string is 
extracted or inserted as the information passes through the rotator 

into either buffer, and then the buffer is gated to its destination. | 


24 


Read Buffer | 


Write MIR. 


Dat: 
Rotation 
Control 


Parity 
Check 7 


36 


| Write Buffer 


35 


Read MIR 


Data 
= en, Control 


Figure 6. Field Isolation Unit (Memory/Requestor Interface) 
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Any port on the interchange (see Figure 3) may read bit strings from 
memory. The port must supply a bit location, a string length (in bits), 
and a field direction (one bit meaning forward or reverse) to the FIU, 
which places the information into its Memory Address Register. Becsuce 
fields may be manipulated in either direction, locations actually refer 
to between-bit positions, as illustrated in Figure 7. The thirteen bits 
from location 13 forward are the same thirteen as accessed from loca~ 
tion 26 backward. This simplifies microprogramming by naming bit | 
strings in a manner similar to the way in which we think about them. 


i 413 —— 26 


Ser 2 ern Reh a Ot i a nace tnemecamA P 


NOG000000 N000 


Ob maoeanceae 


Figure 7. Defined-field addresses labelling between-bit positions. 


Given a field location, the FIU calculates which byte in the conventional 
memory contains the leading bit. On the B1700, there are four 9-bit 
memories (one bit of which is used for parity). Consequently, the low 
three bits of an address specify a bit position within a word, the next 
two bits specify one of the four memories, and the high 19 bits con- 
stitute a conventional address, The leading bit is in the word specified 
by the high 21 address bits, This word, and the corresponding words in 
the other memories, are brought to the FIU's Read MIR. For example, the 
accessed words which satisfy a request for the 13-bit field beginning 

at location 13, forward, are shaded in Figure 8. The field itself is 
doubly shaded. From the low three bits and direction of a request, 

the FIU. is told how many positions and in what direction to rotate the 
received field in order to right-justify it. The request length is used 
to create a mask which zeros the unneeded high bits. The isolated field 
is then sent to the port interchange, as shown in Figure 9. 


Requests 
Location--— 
0000000000000000000 
. 01 


Length-- | 
0000000000001101; 
Direction-- 


03 


101; 


word, 


memory y. 


bit 
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Bit Address 


-memO mem 1 mem 2 mem 3 


: (Parity bits not shown) 


Figure 8. Words (shaded cells) delivered to FIU satisfying 
aia request for 13 bits beginning with location 13, 


forward. 


To Port Interchange 


' Figure 9. Read field isolate. 


€rom 


4 S-memory 
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On the B1700, the field is available at a processor's port 668 nsec after. 
the read request is initiated, assuming the port interchange and memory are 
both free. The port and FIU are involved during the bast. 506 nsec. | 

To write bit strings into memory, the FIU sbeepts a request (i.e., location, 
length, direction) and performs a read cycle to bring the receiving memory 
field to the Read MIR and right-justified through the rotator. It then 
accepts a bit string from the port interchange which goes through the Write 
MIR and is masked into the memory field at the rotator. Then the rotator 
returns the information to word-alignment, and passes it through to the 
write buffer, where it returns to memory. Write cycles involve ports for 
500 nsec and the FIU for 1169 nsec. : oO : 


Since writes are performed as Read-Modify-Write, the addressed field, as 
it was before modification, is available in the read buffer for the re- 
questing port. Thus, fields may be swapped between memory and a processor 
by one microinstruction. It is also possible to force two back-to-back 
requests, which. gives any processor the ability to test and set, and re- 
store a bit string in one uninterruptable operation. This is vital £or 
administering multiprocessor, multiprogramming environments because it 
can be used to prevent system deadlocks, | 


Recause the amount of iatouaeion which resides with the processor is so 
._ large (registers plus M-memory), one processor uses only 20% of the 
available S-memory cycles, which enables one FIU to support several _ 
processors, In addition, almost 80% of processor requests are reads. 


Of the 41 bits required to specify a memory request, typically 5-10 come. 
from the S-instruction. The rest come from other S-machine state. They 
represent the context within which the S-machine is working. The length 
field, for example, constantly is 16 when the S-machine is the IBM 1130. 

' Consequently, little work is needed to maintain such large address fields. 


8. SOFT INTERPRETATION 


All Burroughs-supplied interpreters rely on the B1700's Master Control 
Program (MCP) for all input/output, virtual S-memory, virtual M-memory, 
multiprogramming and multiprocessing of user programs, multiprogramming 
‘ and multiprocessing of interpreters, and standard functions. The MCP 

is written entirely in a higher-level language (a synergism of features 
from COBOL, PL/I, and XPL) which is interpreted itself. To provide for 
smooth change of control, a microprogrammed interpreter interfacing 
routine, named Gismo, exists in the beginning memory locations. By 
loading.a pointer to another program into a processor register and clearing 
the microprogram address register, each interpreter transfers to Gismo. 
Gismo uses the program pointer to establish processor context within the 
new interpreter. Subsequent microinstructions are taken from the new | 
interpreter, 
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8.1 . Interpreter-Machine Interface 


Given this interpreter interface, simple, hardware-oriented tasks such as 
interrupt decoding and priority resolution, M-memory overlay, and 1/0 
transfer, can be included in the interface routine, simplifying the re- 
quirements of an interpreter, 


An interpreter has control of a processor until interrupted by another 
element in the system or by programmatic interrupt. Between each S- 
instruction interpretation (approximately every 35. usec.), every inter- 
preter must examine the processor's interrupt register to detect the need 
for change of control. If an interrupt is present, the interpreter calls 
(instead of transfers to) Gismo, leaving a constant in a register which 
directs Gismo to decode the interrupt. For simple functions such as timer 
interval or 1/0 transfer, Gismo actually performs the required actions. 
For other interrupts, Gismo returns an appropriate description to the 
calling interpreter. 


If the interpreter can handle the interrupt, it does so and continues 
with the next S-instruction if all interrupts are quiet. If it cannot, 
it moves its S-machine's state outside of the processor, loads a constant 
which means "call MCP", and transfers to Gismo. Very little state needs 
to be saved because no S-instruction is in the middle of interpretation. 


Real-time interrupts are distinguished by hardware, but are handled in 
exactly the same way. When Gismo is told to "call MCP", it may select 

a non-MCP program to process real-time interrupts (such as a COBOL routine. 
which performs a pocket select for a document-sorter). 


Gismo is also called by the MCP to move interpreter segments into M-memory, 
by all programs to initiate 1/0, and by the computer operator to oe 
some start-up or post-mortem utility functions. 


8.1.1 S-machine Switching 


Note that change of control is between S-machines, which does not necessarily 
mean a different interpreter is needed. (When all user programs are written 
in the MCP's language, only one interpreter is active.) Each job is re- 
presented in S-memory according to Figure 10. All but one segment is read- 
only code. The one is called the "run structure" and consists of: I/0 
buffers; data; descriptions of devices and operands; and the run structure | 
nucleus which contains the: job's S-machine state and MCP-needed control in- 
formation. All segments (except the run structure nucleus) move into memory 
under control of the MCP. The data section may or may not be administered 
internally by a virtual memory discipline. Note that code segments never 
are written out of memory because they never change, The space they 

occupy is always available for other uses. . : 
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The MCP's run structure includes an interpreter dictionary, each entry of 
which describes an interpreter (either active in S-memory or on disk). 


Overlayable program segments 
Overlayable data 


segments | 


| -machine_ state (run_structure) 
Data definitions 


ee ote Se ee 


| 
File definitions | 


| File buffers | 


Figure 10. Program components.. 
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To reinstate a user's interpreter, the MCP extracts from the user's 
S-machine state the name of the interpreter being used. The interpreter 
name is looked up in the interpreter dictionary to yield a pointer to 
the interpreter code in S-memory. The MCP's interpreter then saves its 
S-machine state, loads the pointer into a hard register, and resets the 
Microprogram Base Register and Microprogram Address Register (to leave 
the MCP's interpreter's code space). The next micro is brought from 
Gismo, which uses the hard register to load the Microprogram Base 
Register, transferring microinstruction fetches to the new interpreter's 
code Spaces Associating S-machines and interpreters symbolically allows 
such things cs several COBOL interpreters active in one mix--one de- 
signed for speed, another for code compaction, etc.,--all employing the 
same S-language expressly designed for COBOL (that is, a COBOL-machine 
definition). 


To switch back to the MCP interpreter, a user sUECEDECEEE obtains a 
pointer to the MCP's run structure from the user program's run 
structure and performs the identical procedure, 


Interpreter switching is independent of ‘any execution considerations. 

It may be performed between any two S-instructions, even without switch- 
ing S-instruction streams. That is, an S-program may direct its inter- 
_ preter to summon another interpreter for itself. This facility is use- 
ful for changing between tracing and non-tracing interpreters auEene 
debugging. 
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Interpreter switching is also independent of M-memory. The Microprogram 
Address Register always actually addresses S-memory. In case M is 
present, special hardware diverts fetches to it, whenever the Microprogram 
Limit Register indicates that M's contents mirror the portion of S-memory 
being addressed. Without M, no fetches are diverted, and Gismo sits in 
low S-memory. 


8.2 Interpreter Management 


Entries in the interpreter dictionary are added whenever a job is in- 
itiated which requests a new interpreter, Interpreters usually reside on™ 
disk, but may be read in from tape, cards, cassettes, data comm, or other 
media. They have the same status in the system that object code files, 
source language files, data files, compiler files, and MCP files all share: 
symbolically-named, media- independent bit strings. While active, a copy . 

is brought from disk, to be available in main memory for direct execution, 
The location may change during interpretation due to virtual S-memory — 
management, so microinstructions are Sac a 


At each job initiation smi termination, the MCP rearranges pa for 
the processor being readied according to five strategies; 


(a) Abundant M 


Condition: All active interpreters can fit in M. 
Action: Place all interpreters into M. 


(b) Ample M 


Condition: All active interpreters can be granted at 
least their minimum M request (usually 
“1000 words = 1000 16-bit micros). 
“Actions Divide M evenly and place part of each 
interpreter in M. ; 


(c) Adequate M 
Condition: Several interpreters can be given their 
| minimums, but not all. 
Action: Give the MCP's interpreter about 1000 
words; divide the rest into 1000-word 


. Blocks and swap all user interpreters 
‘in and out during reinstate operations, 


(d) Precious M 


Condition: Only two interpreters can be given. their 
minimums, 

Action: Give the MCP its minimum; swap all users 
in and out of the rest. 


8.3 
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(e) . Bare M , 
Condition: Only one interpreter can be given a minimum 
demand. 
Action: At each interpreter switch, place one inter- 


preter into all of M. 


Interpreter profile Siaerevies show that 1000 micros (1060 words) | 
account for over 99% of all instructions executed, even though 
most interpreters are 2000 words long. If a niberonros«aimes is 
prudent enough to rearrange his code according to usage, then an 
interpreter requesting 1000.words of M as a minimum may be as 
efficient as one peghees she: 2000 words. 


Ease of Microprogramming 


‘Writing microprograms for the B1700 is as simple, and in some ways simpler, 
than writing FORTRAN subroutines: ‘oi 


(a) ee consist of short, imperative English sentences 


r] 


and narrative comments, For example, one subroutine in 
the PORTRES interpreter reads as follows; . 


* Dpecinal to binary conversion ey 2 
* . Source: addressed by F; 1-13 digits 
* . Destination: L Y, initially zero 


Decimal-to-binary | : 
Read & bits to T counting FA up and FL down obtain a char 
and address the next one 


Move T,. to xX | strip off zone bits 
Call Adid- X- to-LY LY — LY + X add to partial sum 
If FL=0 then exit ‘quit after last char 
Move L to X | | allow another digit: 
Call Multiply-XY-by-10 - .. TL -— 16 x RY 
_ Move L to Y LY - 
Move T to L Le 


Go to Decimal- Sse vinaeys repeat 


(b) Knowledge of microinstruction forms is not beneficial. 
Although microprogrammers on other machines need to know 
which bits do what, on the B1700, there is no way to use 
that information. Once the function is given in English, 
its representation is immaterial. The B1700 microprogrammer 
has only one set of formats to worry about: those belonging 
to the S-language which he is interpreting. 
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(c) Multiprogramming of microprograms is purely an MCP function, 
carried out without the microprogrammer's knowledge or 
assistance, Actually, there is nothing one would do differently, 
depending on whether or not other i are. running 
Sm NESne Oey: 


(d) Use of M-memory is purely an MCP function; the resident 

interpreter interface alone can move information in 
and out of M. Other than rearranging one's interpreter 
accotding to usage, there is nothing one should microprogram 
differently depending on whether microinstructions are 
executing out of M-memory or S-memory. -Maximizing use of 

- system resources is beyond the scope of any individual pro- 
gram; responsibility lies solely with the MCP and the machine 
designers. : 


(e) Since all references are made symbolically, protection is 
easy to assure. Microprograms can reference only what they 
-¢an name, and they can only name quantities belonging to 
themselves and their S-machines. Moreover, names cannot 
be. artifically generated, as they can in FORTRAN (e.g., by 
negative subscripts, or by call-by-value paceiererS used 
in call-by-reference Song Para 


(f) Calling out interes is simplified by the continuation 
of Burroughs' "one-card-of-free-form-English" philosophy 
of job control language. Figure 11 shows the control informa- 
tion which creates a new interpreter (1) from cards, and 
(2) from a disk file named XCOBOL/SOURCE. 


(1) 2 COMPILE XCOBOL/INTERP WITH MIL; DATA CARD. 


(2) 2? COMPILE XCOBOL/INTERP WITH MIL; MIL FILE CARD = 
XCOBOL/ SOURCE 


_ Figure 11. Typical MCP control information 
for creating interpreters. 


_(g) Association of interpreters and S-language files occurs at 
run-time. Figure 12 shows the control information which 
executes a COBOL program named FILE/UPDATE with (1) the. 
usual COBOL interpreter, and (2) another interpreter named 
-XCOBOL/INTERPRETER. | 
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(1) 2? EXECUTE FILE/UPDATE 


(2) 2 EXECUTE FILE/UPDATE; INTERP = XCOBOL/INTERPRETER © 


’ 


Figure 12. Typical MCP control information 
for executing programs. 


(h) There is no limit to the number of interpreters that may be 
in the system (except that no more than 244 bits are capable 
of being managed by the B1700's present virtual memory 
property, so a 28,000-bit average interpreter length means 
there is a practical limit of 628,292,362 interpreters... 
many more than the number of S-languages in the world). 


9. _ VIRTUAL MEMORY 


On the B1700, S-language addresses may be 44 bits long (disregarding the 
possibility of using magnetic tape as a backup for main memory), even 
though each system will have 16 million bits of S-memory or less. M- 
addresses are 24 bits long, even though each system will have 65,536 bits 
of M-memory or less. Virtual memory is the mechanism by which the B1700 
accommodates memory references to more bits than are physically attachable, 


9.1 Virtual M-memory 


As control is switched fe an interpreter, two nea are set bg the | 
ee piss ; ieebeey ss ores “pea renrg bee 


sein ics cantatas a velabivecpliads 


Micros are pie a ecaices 


This is not a true virtual memory scheme since early interpreter locations 
are always in M-memory, and later locations never are. It does have the 
necessary property, however, that the actual amount of M-memory never 
impacts the program, Interpreters execute identical sequences of instruc- 
tions for a given task as the amount of M-memory varies. The micro- | 
programmer never takes cognizance of the actual amount of M-memory that 

is present. (He should, of course, arrange his interpreter with the most 
often used parts first. ) 
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9.2, Virtual S-memory 


The B1700 MCP maintains a large disk area for program pieces that are not 

in use and can be kept outside of main memory. These pieces may be any 
number of bits long ‘(up to 224) ,. Whether they are segments, pages, arrays, 
or otherwise, depends on the S-machine from whose environment they came. 

All Burroughs S-machines designed for specific programming languages (e.g., 
COBOL, FORTRAN, RPG, BASIC, ALGOL) make references through descriptors, or 
interpretable pointers. These descriptors define areas within an S-machine's 
data or code space; references are relative to the start of the described 
area, The descriptions themselves are relative to the start of the 
S-machine's space, or to an MCP back-up area. When a reference selects an 
area which is not in memory, the MCP initiates a disk request and temporarily 
runs another job. When the absent area is brought in, its descriptor is 
changed to indicate the new POeAETONS? The reference is retried when the 

job is selected again. | 


S-machines are free to manage their own data and code spaces, with and 
without the MCP's assistance. 


Within an S-machine, only its own data and code spaces are accessable, 
Each machine environment is represented as if it began in location zero 


ene extended throughout all memory, possibly up to 2 as (over 17 trillion) 
bits' worth. The B1700 monitors all references te main memory to verify 
that they lie between locations contained in the hardware's Base and Limit 
registers which are set by the MCP during reinstating. Illegal references 
_ cause a hard interrupt which transfers control from a user interpreter 
_back to the MCP's interpreter, preventing meddling in other S-machine's 
areas. | | 


10.° . STACK ORGANIZATION 


Present arreraeeber sviechiae assumes that no 
Sitormation remains pushed into the stack. 


Other hardware makes S-machine stacks easy to implement. The ability to 
read and write in both directions in S-memory, and to count field defini- 
tion registers’ subfields up and down independently give microprograms 
read-and-pop and write- and-push operations which can be carried out by one 
microinstruction. . 
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li. DYNAMIC SYSTEM CONFIGURATION 


Since no information (other than a few MCP tables) contains absolute 
-memory locations, the presence or absence of particular memory modules 
is irrelevant. Should one fail, it may be taken off-line and repaired 
without disturbing the rest of the system. Conversely, when memory 
modules are added to the system, the B1700's location-independent 
segments can be placed in them as soon as they are brought on-line, No 
code in the NCP nor in any user program need ever be PEN ESee due to 
memory reconfiguration, 


Likewise, the identity of any processor, I/O channel, or peripheral is 

not represented in any user program or MCP routine. When particular 
devices are needed, their identity is looked up using a symbolic reference 
each time a device is accessed. Consequently, devices may leave the 
system without inhibiting any prdégram from running (unless the MCP is. 

not able to create a pseudodevice to hold the I/O requests until the 

real device is available again). Further, devices may enter the system 
and be fully utilized without changing any user or MCP code. 


12. MULTIPROGRAMMING 


A misunderstood concept, multiprogramming refers to the interlaced pro- 
cessing of independent programs using as much of an entire system's 
resources as are required. It is usually confused with partitioning, 
which is the interlaced execution of independent programs using part 
.of a system's resources. Under multiprogramming, two three-tape sorts 
which use 24K of core can be run together on a three~-tape, 24K system 
(the MCP must utilize three pecudestepeny: a partitioned system needs 


six tapes or 48K or both. 


A elec way to implement multiprogramming is to represent each program 
in main memory exclusively; that is, no state information or temporary 
results are kept in a processor...everything is available in memory. 
On the B1700, this is true of each S-machine. To interlace processing 
of each program, imagine directing the processor to execute exactly one 
instruction from each program, in round-robin fashion. Since everything 
nhecessary for any instruction's execution is represented in memory, no 
difficulties are encountered in passing from one program to the next. 
Such an approach, however, denies the efficiencies which can be obtained 
by successive instruction executions in one processor, The Bl1700 takes 
an intermediate approach which is made feasible by its ciel 
Obzeni zed virtual memory scheme. #achiprariEridsmarariens 

bs o@, either for 1/0 or virtual memory eee ee arem 
When a program can go no further by itself, 
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its state is recorded in memory and another task is taken up. It is a 
happy discovery that such breakpoints occur often enough to keep the MCP 
attentive to the needs of many jobs. This scheme is further refined by 
allowing programs to. become dormant, which permits their state informa- 
tion to be taken out of main memory. Subsequent I/0 operations on which 
dormant programs may be waiting carry some form of identification which 
ties them to the dormant program, and causes program state information 
to be brought back. eae f° te 


13. MULTI.PROCE SSING 


Multiprocessing is the concurrent execution of more than one processor on 
independent programs. The processor-independent program state, which is 
used to keep multiprogramming simple, automatically allows any program 
to be resumed by any processor, as long as each processor can address all 
of memory, communicate with the entire I/O system, and has access to the 
interpreter named in the program's run structure (see Figure 10). All | 
of these conditions are always true of B1700 processors. 


14, DESCRIPTOR-ORGA? SIZED 1/0 


Because I/O processing is often not directly dependent on subsequent pro- 
gram steps, greater throughput can be achieved by overlapping 1/0 pro- 
cessing With other processor activity. So, to reduce BL/O0 processor 
involvement with I/0, requests take the form of descriptors (interpret- 
able programs) whose effect, when interpreted, is the I/O function. To 
‘activate a request, a processor sends a port-to-port message across the 
port interchange. The message locates an I/O descriptor in main memory 
which an I/O processor will interpret. Non-I/O processors are thus 
relieved of the intricacies of device and channel communication. 

On oné-processor Bi/O0 systems, the only [I/O d ptor ich are fab- 
ricated are self-evident to the device controls themselves. Each contains 
a literal device name and an opcode for the device, as well as the 
addresses to be used for information transfer in and out of memory. On 
multi-processor B1/760 systems, the opportunity to create arbitrary des- 
criptors is present, enabling file-oriented activities, such as record 
accessing, searching, and sorting, to be carried out in the I/O realm. 

In addition, new device disciplines can be accommodated by new microcode 
for the 1/0 processors. 


15. SYSTEM PERFORMANCE MONITORING 
I5.1 Profile Statistics 
Whereas hardware receives extensive and penetrating scrutiny while it is 


being designed, software is normally constructed with only the programmer's 
intuitions about its efficiency to guide its-design. The performance 
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measurement technique of profile statistics, the association of code usage 
with a program's source language, has been reported to help improve a 
program's running time by a factor of two to ten. (See Darden and Heller, 
or Knuth [Profile! ). To help B1700 users obtain the greatest throughput 
per dollar, each Burroughs interpreter can gather profile statistics about 
a program which it is interpreting and present them at the end of a run. 


At compile time, a user may indicate which portions of his program are to 
receive more or less scrutiny. These indications define a set of program 
segments whose usage is to be recorded By means of an inserted S- pangusee 
monitoring command. 

The compiled Steet consists of: the code segments expanded with monitors 
(by less than 1%), textual information which will be used to describe the 
participating program segments in terms of source language, and an array. 
of cells for the frequency counts. Interpretation of the monitors appears 
to extend execution times by less than 4%. After execution, the weighted 
frequency counts show which program segments account for most of the 
running time. Reprogramming these critical eEeenes Ox efficiency will 
reduce running times the most. 


Microprogramming can easily allow dynamic measurements of other PeORSrE nee 
as well, with similarly small overhead. 


15.2 "Monitor" Microinstruction 


One microinstruction, Monitor, simply presents a user-specified bit pattern 
at designated pins in the processor backplane and frontplane. This allows 
unique software "events" to be identified by external hardware, which 
greatly simplifies the task of knowing what the system is doing. 


Each higher-level language has been extended to include a construct which © 
generates a Monitor S-instruction for each interpreter to carry into an 
identical microinstruction. Event flagging is thus available to all 

_ programmers. . : 


16. EVALUATION 


~The B1700's ability to provide profile statistics at negligible cost voids 
all known system performance measures. Consider benchmarks, which measure 
more system parameters than any other technique. 

Any benchmark program which runs on the B1700 develops not only an observed 
running time, but also an indication of how to reduce that time (often by 
more than 50%). What, then, is the true performance on the system? Not 
the observed time, because inefficiencies are pin-pointed. Half the time? 
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Not until the benchmark has been changed. The point of benchmarks is to 
have a standard reference which allows the customer to characterize his 
work and obtain a cost/performance measure, What customer would be 
satisfied with an inefficient characterization? If the Bl700 can show 
that a program is not using the system well, what good is it as a bench- 
mark? If we change the program to remove the inefficiencies, it is no_ 
longer standard. This is a pernicious dilemma. 


evar the simplest measure, add time, still published as if it hasn't been 
a misleading and unreliable indicator for the past 15 years, is void. 

What is the relative performance of two machines, one of which can do an 
almost infinite variety of additions and the other of which can do only 
one or two? The B1700 can add two 0-24 bit binary or decimal numbers 

in 187 nsec; how fast must a 16- bit binary MeGHIne be in order to have. 
an equivalent add time? 


Assuming reasonable benchmark figures are obtainable, they would say 
nothing about the intrinsic value of a machine which can execute another 
machine's operators, for both existing and imaginary computers; which 
can interpret any current and presently conceivable programming language; 
which can always accept one more job into the mix 3 which can add on one 
more peripheral and one more memory module, to grow with the user; which 
can interpret one more application-tailored S-machine; which can tell a 
prograrmer where his program is least efficient; which can continue 
operation in spite of failures in processing, memory, and I/O modules. 
_ These characteristics of the B1700, shared by few other machines--no 
‘machine shares them all--save time and money, but are not yet part of 
any performance measurement, | ; 


Despite the nullification of measures with which we are familiar and the 
gargantuan challenge of measuring the B1700's advancements of the state- 
of-the-art, there are, nevertheless, some quantifiable signs that the 
system gives more performance than comparably-priced and higher-priced 
equipment. 


16.1 Utilizdtion of Memory 


Defined-field design's major benefit is that information can be re- 
presented in natural containers and formats. Applied to language inter- 
pretation, defined-field architecture allows S-language definitions which 
are more efficient in terms of memory utilization than machine architec- 
tures which have word- or byte-oriented architecture. For example, short 
addresses may be encoded in short fields, and long addresses in long 
fields (assuming the interpreter for the language is programmed to decode 
the different sizes.). Alternatively, address field size may be a run- 
time parameter determined during compilation. That is, programs with 
fewer than 256 variables may be encoded into an S-language that uses 
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eight-bit data address fields. Even the fastest microcode that can be 
written to interpret address fields is able to use a dynamic variable 
to determine the size of the field to be interpreted, 


Just how efficient this makes S-languages is difficult to say because no 
standard exists. What criterion will tell us how well a given computer 
represents programs? What "standard" size does any particular program 
have? We would like a measure that takes a program's semantics into 
account, not just a statistical measure such as entropy. 


If we simply ask how much memory is devoted to representing the object 
code for a set of programs, we find the following statistics: 


Language Aggregate Aggregate Other % Improved B17/60 


of Sample Size on B17/60 Size on Other System Utilization 
FORTRAN 280KB 560KB - System/360 50% 
FORTRAN 280KB ue 450KB B3500 407, 
COBOL. 450KB © 1200KB B3500 - 60% 
COBOL 450KB 1490KB System/360 70% 
RPG II 150KB 310KB System/3 507 


In short, the B1700 appears to require less than half the memory needed 
by byte-oriented systems to represent programs. Comparisons with word- 
oriented systems are even more favorable. 


As to memory utilization, the advantage of the B1700 is even more apparent. 
_ Consider two systems with 32KB (bytes) of main memory, one a System/3, the 
other a B1700. Suppose a 4KB RPG II program is running on each. If we 
ask how much main memory is in use, we find: . 


' System Bytes in Use yA Comment 
System/3 32K 100 28K is idle without multi- 
oo . programming and virtual: memory. 
B1700° ; 1K 3 Assumes 500B run structure 
-and 500B of program and data 
segments, 


In other words, the utilization at any given moment may be 30 times better 
on the B1700 than on the System/3. At least, with all program segments in 
core, it is seven times better (4.5KB vs. 32KB). Even if we assume that 
the RPG interpreter is in main memory and is not shared by other RPG jobs 
inthe mix, the comparison varies from 6:1 to 4:1, 5KB to 8KB (vs. 32KB), 
-84% to 757, better utilization. As more and more RPG jobs become active in 
the mix, the effect of the interpreter diminishes, but then comparison 


May 1972 


becomes meaningless, because other low-cost systems cannot handle so large 
a mix. (Note that these fisures change when a different main memory size 
is considered, so the comparison is more an illustration of the advantage 
of the B1700's variable-length segments and virtual memory than of its 
memory utilization.) 


16.2 Running Time 


Although program running time is said to involve less annual cost at 
installations than the unquantifiable parameter which we may call "ease 

of use", let us mention some current observations. When the B1/00 inter- 
prets an RPG II program, the average S-instruction time is about 35 micro- 
seconds, compared to System/3's 6 microsecond average instruction time. 

On a processor-limited application (specifically, calculating prime numbers), 
the identical RPG program runs in 25 seconds on a B1700 and 208 seconds on 

a System/3 model 10. Both systems had enough main memory to contain the 
complete program; only the ua Ey, and processor were used. 


The particular configurations leased for $3500 (B1700) vs. esaee (System/3). 
In terms of cost, the B1700 run consumed 30¢ while the System/3 run took 
$1.60. In terms of instruction executions, the B1700 was 50 times faster. 
That is, each individual interpreted RPG instruction, on the average, con- 
tributed as much to the final solution as 50 System/3 machine instructions. 
When one considers that RPG is the only programming language on the 
System/3, it is incredible that System/3 seems so poorly equipped to run 
RPG programs. It is even more incredible because the B1/700 really has no 
S-language expressly for RPG; it uses the COBOL S-language instead. The 
likelihood of an S-machine more than 50 times more efficient than System/3 
is almost certain. This seems to support the B1700 philosophy, that in- 
terpretation of S-machines for each application is more efficient enous 
using a euskal: purpose architecture. 


Using Samehee set of benchmark programs (for banking applications), and 
another B1/700 which leases for $2000, throughput comparisons are again 
astounding. Orf the one hand, we are comparing a defined-field, soft- 
interpreting, soft-1/0-processing machine using pre-release compilers, 
interpreters, and MCP routines, under multiprogramming, multiprocessing, 
virtual memory systems design, against, on the other hand, a byte-oriented, 
hard-wired system with two years! field testing, five software releases, 
_batch-processing, one cpu, and 32K maximum main memory. Despite all of 
the B1700 features, which supposedly trade speed for flexibility, the 

' B1700 executes RPG: programs in 50% to 75% of the System/3 time, and 
compiles them in 110% of the System/3 time, for the same monies) rental. 
In applications of this type, compilation is expected annually (monthly 
at worst) while execution is expected daily. (Systems used for this 
comparison included a multi-function card unit to read, print, and punch 
96-column cards, a 132-position 300 lpm printer, a dual spindle 4400 bpi 
disk cartridge drive, and operator keyboard. The System/3 could read 
cards at 500 cpm, while the B1700 could read at 300 cpm.) 
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17s CONCLUSION 


Microprogramming, firmware, user-defined operators, and special-purpose 
minicomputers are being touted as effective ways to increase throughput 
on specific applications while decreasing hardware costs. Standard 
system modules may be tailored to an installation's needs. Effective 

as these approaches are, they are all held back by procrustean machine 
architecture. Burroughs Bl1700 appears to eliminate inherent structure 
by its defined-field and soft interpretation implementation. Both are 
advancements of the state-of-the-art. Now one machine can execute every 
machine language well, eliminating nearly all conversion costs. One 
machine can interpret every programming language well, reducing problem- 
solving time and expense. The B1L70G does not waste time or memory over- 
coming its own physical characteristics; it works directly on the 
problems. Furthermore, these innovations are available in low-cost 
systems that yield better price/performance ratios than conventional 
machinery. Z . : | 
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